chore(deps)(deps-dev): bump the dev-tooling group across 1 directory with 7 updates#1358
chore(deps)(deps-dev): bump the dev-tooling group across 1 directory with 7 updates#1358dependabot[bot] wants to merge 1 commit into
Conversation
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
dependabot
Bot
requested review from
Jurij89,
branarakic and
zsculac
as code owners
| vitest: | ||
| specifier: ^4.0.18 | ||
| version: 4.0.18(@types/node@22.19.11)(happy-dom@20.8.9(bufferutil@4.1.0)(utf-8-validate@5.0.10))(jiti@2.7.0)(tsx@4.21.0)(yaml@2.9.0) | ||
| version: 4.1.9(@types/node@26.0.1)(@vitest/coverage-v8@4.1.9)(happy-dom@20.8.9(bufferutil@4.1.0)(utf-8-validate@5.0.10))(vite@8.1.0(@types/node@26.0.1)(esbuild@0.27.3)(jiti@2.7.0)(tsx@4.22.4)(yaml@2.9.0)) |
There was a problem hiding this comment.
🟡 Issue: Make the toolchain version policy explicit instead of lockfile-driven
What's wrong
This PR is a toolchain upgrade, but the structure leaves version ownership scattered. The manifests do not clearly say whether the workspace standard is Vitest 4.1.9, Vite 8.1.0, or simply whatever the current lockfile selected. That makes future maintenance harder because reviewers have to reverse-engineer policy from pnpm-lock.yaml rather than from a clear package-management boundary.
Example
A future dependency refresh can keep package manifests looking unchanged while moving the actual test/build stack again, because the intended versions live partly in one exact devnet pin and partly in lockfile resolution side effects.
Suggested direction
Centralize these build/test tool versions or update all relevant workspace manifests consistently. Avoid having one package exact-pin Vitest while the rest rely on old ranges that happen to resolve to the new version in this lockfile.
For Agents
Look at package.json, pnpm-workspace.yaml, and the workspace package manifests. Preserve the resolved Vite/Vitest versions, but move the version policy into a single explicit place, such as a pnpm catalog or consistent manifest spec updates, then regenerate pnpm-lock.yaml and verify pnpm install is stable.
| "three": "^0.184.0", | ||
| "typescript": "^5.7", | ||
| "vite": "^6", | ||
| "vite": "^8", |
There was a problem hiding this comment.
🟡 Issue: The Vite 8 upgrade is not validated against the Node UI production bundle
What's wrong
This dependency bump changes the toolchain for the published Node UI bundle, but the normal PR workflow intentionally avoids that bundle build. Existing tests exercise Vitest and the Vite dev server, which does not prove the production vite build path still works after a major Vite/plugin-react upgrade.
Example
A Vite 8 production-only break, such as changed asset handling or build-time plugin behavior, could still pass the current PR CI because node-ui unit tests and Playwright run without executing pnpm --filter @origintrail-official/dkg-node-ui run build:ui.
Suggested direction
Add CI or PR validation that runs the affected production bundle command before merging this dependency upgrade.
Confidence note
I could verify the CI definitions in the workspace, but not PR run results. The finding is about missing PR-level validation in the checked-in workflow.
For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the existing fast package build, but add a focused PR validation step for the Vite production bundle, for example pnpm --filter @origintrail-official/dkg-node-ui run build:ui, or otherwise document/link evidence that the PR ran the release pnpm build path.
There was a problem hiding this comment.
🟡 Issue: The Vite 8 upgrade is not validated on the production node-ui bundle path
What's wrong
This PR upgrades the toolchain that builds the shipped Node UI static bundle, but the visible validation covers tests and dev-server e2e rather than the production vite build artifact. That leaves a user-facing release path unverified for a major bundler/plugin upgrade.
Example
A regression where Vite 8 changes production bundling, asset paths, or plugin-react behavior could make pnpm --filter @origintrail-official/dkg-node-ui run build:ui fail or emit a broken dist-ui/, while the current PR checks still pass because they test node-ui Vitest and Playwright dev-server paths only.
Suggested direction
Add CI or documented validation evidence that runs the node-ui production Vite build after the Vite/plugin-react upgrade, ideally as a targeted build:ui check so the release artifact path is covered.
For Agents
Look at packages/node-ui/package.json and CI. Preserve the existing fast build:packages path if needed, but add explicit validation for the changed production bundle path, such as a PR check running pnpm --filter @origintrail-official/dkg-node-ui run build:ui or root pnpm build for dependency-upgrade PRs. The proof should fail if Vite/plugin-react cannot produce dist-ui.
There was a problem hiding this comment.
🟡 Issue: Vite 8 production UI bundle is not verified on PRs
What's wrong
This dependency bump changes the tool that creates the published Node UI static bundle, but the PR validation paths I found do not exercise that production bundle. That leaves release-facing breakage possible even when the PR CI is green.
Example
A regression where pnpm --filter @origintrail-official/dkg-node-ui run build:ui fails under Vite 8 would not be caught by the existing PR checks: node-ui unit tests and Playwright e2e exercise the Vite dev server, while the shared CI build intentionally omits the production dist-ui bundle.
Suggested direction
Add a focused PR validation step for the Node UI production bundle, or otherwise require documented evidence that build:ui passes with Vite 8 before merging this dependency bump.
For Agents
Look at packages/node-ui/package.json, scripts/build.mjs, and .github/workflows/ci.yml. Preserve the fast package build if needed, but add validation for the changed production Vite bundle path, for example a focused CI step or required evidence running pnpm --filter @origintrail-official/dkg-node-ui run build:ui after the Vite upgrade.
There was a problem hiding this comment.
🟡 Issue: Centralize the frontend toolchain versions
Why it matters
This PR updates the same frontend toolchain across multiple packages but keeps the version policy scattered, with node-ui using broader major ranges than network-sim/graph-viz. The lockfile currently pins one resolution, but the manifests do not give maintainers a single place to understand or update the intended toolchain version.
Suggestion
Consider moving shared build/test tool versions such as vite, @vitejs/plugin-react, vitest, and @vitest/coverage-v8 into a pnpm catalog or another single repo-owned version policy, then reference that from the package manifests. That would make future toolchain bumps one deliberate edit instead of several package-local range changes.
The Vite 8 bump is not validated against the node-ui production build in PR CI
What's wrong
This dependency bump changes the toolchain used for the shipped node-ui bundle, but the visible PR validation paths exercise TypeScript build, Vitest, and Vite dev-server E2E rather than the production build:ui command. That leaves a real gap for production-only Vite failures.
Example
A Vite 8 regression that only appears during production bundling, such as asset emission, CSS processing, or chunk generation, could make pnpm --filter @origintrail-official/dkg-node-ui build:ui fail while the existing PR build, unit tests, and Playwright dev-server E2E remain green.
Suggested direction
Add a CI step or documented validation evidence for the node-ui production vite build path when upgrading Vite/plugin-react.
Confidence note
I inferred this from the checked-in scripts and workflow configuration; I did not run the CI jobs in this read-only review environment.
For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the existing unit and E2E lanes, but add PR validation for pnpm --filter @origintrail-official/dkg-node-ui build:ui or run the root build path that includes it; the check should fail if Vite 8 cannot produce the production UI bundle.
There was a problem hiding this comment.
🟡 Issue: Centralize the frontend toolchain version policy
Why it matters
The PR updates the same frontend build toolchain in multiple workspace manifests, but leaves slightly different version ranges. The lockfile currently resolves one version, yet future installs or follow-up bumps can drift by package, making toolchain upgrades harder to audit.
Suggestion
Consider introducing a pnpm catalog for shared dev-tool versions, or at least use identical specifier text for Vite and the React plugin across the affected packages. That keeps the update as one policy decision instead of three subtly different local choices.
The node-ui Vite 8 production build is not covered by PR validation
What's wrong
This dependency bump changes the tool that produces the published/runtime node-ui browser bundle, but the existing PR checks appear to exercise only TypeScript compilation, unit tests, and Vite’s dev server. That leaves the release-facing vite build path unverified for a major Vite/plugin-react upgrade.
Example
A Vite 8 production-only regression, such as a changed build-time asset transform or unsupported production option in packages/node-ui/vite.config.ts, could make pnpm --filter @origintrail-official/dkg-node-ui build:ui fail while the current PR checks still pass because they run tsc, unit tests, and vite dev server.
Suggested direction
Add a CI step or required validation command for the node-ui production bundle, not just the dev server and TypeScript build, before accepting the Vite major upgrade.
Confidence note
I did not run CI in this read-only environment; this is based on the package scripts and workflow commands in the repository.
For Agents
Look at packages/node-ui/package.json, packages/node-ui/vite.config.ts, and .github/workflows/ci.yml. Add PR validation that runs pnpm --filter @origintrail-official/dkg-node-ui build:ui or include node-ui build:ui in the CI build graph when Vite/plugin-react are bumped. The proof should be that the production UI bundle succeeds under the upgraded Vite version.
There was a problem hiding this comment.
🟡 Issue: Vite 8 upgrade lacks a production bundle check
What's wrong
The dependency change alters the production UI bundler, but the existing validation path does not build the production dist-ui bundle on pull requests. That leaves the release/static UI path unverified for this major Vite/plugin upgrade.
Example
A Vite 8 production-only regression, such as a build-time plugin/config incompatibility or bad generated /ui/ asset path, could make pnpm --filter @origintrail-official/dkg-node-ui build:ui fail or emit a broken dist-ui bundle while the current PR gates still pass because they exercise Vitest and the Vite dev server.
Suggested direction
Add CI coverage for the node-ui production Vite build, and consider serving the built dist-ui in a lightweight smoke test so the upgraded bundler path is actually verified.
For Agents
Check packages/node-ui/package.json, root build scripts, and .github/workflows/ci.yml. Add a PR validation step for pnpm --filter @origintrail-official/dkg-node-ui build:ui or build:full; ideally add a small smoke that serves dist-ui and loads /ui/ so the production Vite 8 output is covered while preserving the existing dev-server e2e lane.
There was a problem hiding this comment.
🟡 Issue: Vite 8 production UI build is not validated
What's wrong
This PR upgrades the build tool used for the published Node UI static bundle, but the visible validation only exercises tests and the Vite dev server. The production bundle path can break differently from dev-server mode, so the dependency bump is not adequately verified for the artifact users receive.
Example
A Vite 8 production-only regression in asset URLs, base: '/ui/', or bundle generation could still pass CI because pnpm --filter @origintrail-official/dkg-node-ui test and the Playwright dev-server lane never run pnpm --filter @origintrail-official/dkg-node-ui build:ui.
Suggested direction
Add CI or PR evidence that runs the Node UI production Vite build after this major Vite/plugin upgrade, ideally scoped to packages/node-ui so it does not undo the rest of the CI optimization.
For Agents
Look at packages/node-ui/package.json and CI build jobs. Preserve the existing fast package build, but add validation for the Vite 8 production bundle, such as a targeted pnpm --filter @origintrail-official/dkg-node-ui build:ui smoke job or including build:full/build:runtime in the dependency-upgrade validation path. The proof should fail if vite build cannot emit dist-ui with the configured /ui/ base.
There was a problem hiding this comment.
🟡 Issue: Centralize shared toolchain versions instead of adding per-package range drift
What's wrong
The PR updates shared build/test toolchain versions by editing individual package manifests, but the same tools are now expressed with different range styles and one package-specific pin. These differences do not appear to encode package-specific intent, so they make future upgrades and lockfile reviews harder than necessary.
Example
A future dependency bump now has to answer whether ^8, ^8.1.4, ^6, ^6.0.3, and one exact Vitest pin are intentional package-level policies or just incidental update drift. That is avoidable metadata complexity for one shared toolchain.
Suggested direction
Use a single workspace-level version policy for Vite, @vitejs/plugin-react, Vitest, coverage, and Node types. A pnpm catalog would make the dependency update read as one coherent toolchain upgrade instead of several near-duplicate local edits.
For Agents
Inspect pnpm-workspace.yaml and the changed package.json files. Preserve the resolved tool versions, but move shared dev-tool versions into a pnpm catalog or otherwise normalize the same specifier across packages. Prove the lockfile remains equivalent after reinstall.
Vite 8 upgrade is not verified for the production UI bundle
What's wrong
The changed dependency affects vite build, but the validated package build path only runs TypeScript for node-ui. That leaves the shipped UI bundle path untested for this major Vite/plugin-react upgrade, so CI can go green while the production dashboard build is broken.
Example
A regression in Vite 8 production bundling could still pass pnpm run build:packages because @origintrail-official/dkg-node-ui only type-checks there. A direct check like pnpm --filter @origintrail-official/dkg-node-ui run build:ui is the behavior that would fail if the upgraded Vite/plugin-react stack cannot emit the shipped UI bundle.
Suggested direction
Add a CI/build validation step that executes the node-ui production Vite build, or document evidence from an equivalent existing job if one is intended to cover it.
For Agents
Look at packages/node-ui/package.json, root build scripts, and CI. Preserve the existing package build behavior, but add validation for the Vite production UI bundle after this dependency upgrade, either by running pnpm --filter @origintrail-official/dkg-node-ui run build:ui in CI for this lane or by making an existing validated build target include it intentionally.
There was a problem hiding this comment.
🔴 Bug: Vite 8 raises the Node floor beyond the repo Node contract
What's wrong
This dependency bump changes the build/runtime contract for the UI packages, but the repo still tells users and CI to use generic Node 22. That generic range includes Node 22 minors below 22.12, which the new Vite toolchain does not support, so normal repo setup can land on a Node version that cannot reliably run the changed build/test commands.
Example
A contributor or release runner with Node 22.5 installed runs nvm use from this repo and then pnpm --filter @origintrail-official/dkg-node-ui run build:ui. The repo-selected Node version is inside the documented Node 22 lane, but Vite 8/plugin-react 6 declare that runtime unsupported; the expected behavior is that the repo's pinned Node version satisfies every build tool's runtime contract.
Suggested direction
Align the repo-supported Node version with the new toolchain before merging, preferably by pinning .nvmrc/docs to a compatible minor or by staying on Vite/plugin-react versions that support the existing Node lane.
Confidence note
CI with node-version-file: .nvmrc may resolve the latest Node 22.x today, but the repo still advertises plain 22, which includes unsupported 22.0-22.11 installs.
For Agents
Check the Vite 8 changes in packages/node-ui, packages/network-sim, and packages/graph-viz. Either raise the repo Node pin/docs/CI floor to at least 22.12 or choose dependency versions compatible with the current Node 22 contract. Prove the fix by installing and running the affected Vite builds under the pinned Node version.
Centralize the workspace toolchain versions instead of updating scattered ranges
What's wrong
This PR upgrades a shared build/test toolchain by editing individual manifests, but the repo still has multiple independent ways to describe the same versions. That keeps future upgrades lockfile-driven and makes it hard to tell which version is the intended workspace standard.
Example
A future lockfile refresh can select different Vite/plugin/Vitest patch or minor versions depending on which package is touched, because the same toolchain generation is expressed with different ranges across manifests.
Suggested direction
Use a single workspace-level dependency policy for shared build/test tools, especially Vite, @vitejs/plugin-react, Vitest, coverage, and Node types. pnpm catalogs would fit this repo better than repeating slightly different ranges in each package.
Confidence note
This is a structural dependency-management concern rather than a behavioral failure; it is worth addressing while the toolchain is being upgraded.
For Agents
Look at package.json, packages/graph-viz/package.json, packages/network-sim/package.json, packages/node-ui/package.json, and the devnet package manifests. Preserve the upgraded toolchain versions, but move shared toolchain versions into one policy such as pnpm catalogs or a repo-owned version map, then have package manifests reference that policy. A lockfile refresh should show the same resolved toolchain set without per-package range drift.
Vite 8 production UI build is not covered by CI
What's wrong
This dependency bump changes the production bundler for the shipped Node UI, but the current validation only covers package builds, Vitest, and the Vite dev server used by e2e. That leaves the release/static-dashboard artifact unverified for the major Vite/plugin upgrade.
Example
A Vite 8 production-only change in HTML transforms, CSS handling, asset emission, or chunk generation could make pnpm --filter @origintrail-official/dkg-node-ui run build:ui fail or emit unusable dist-ui, while this PR's current CI still stays green because it never runs that production build path.
Suggested direction
Add a targeted CI step or job that runs the node-ui production Vite build for dependency-update PRs, or include it in the existing build workflow with an acceptable timeout tradeoff.
For Agents
Look at packages/node-ui/package.json, scripts/build.mjs, and .github/workflows/ci.yml. Preserve the existing fast shared build if needed, but add PR validation for pnpm --filter @origintrail-official/dkg-node-ui run build:ui or otherwise provide CI evidence that the Vite 8 production bundle builds successfully.
There was a problem hiding this comment.
🟡 Issue: The Vite 8 production UI bundle path is not verified
What's wrong
The changed dependency is used by the production Node UI bundle, but the existing CI path explicitly avoids that bundle. That leaves the riskiest part of the Vite major upgrade unverified by the tests/builds that would normally gate the PR.
Example
A PR can pass the existing pnpm run build:packages, pnpm --filter @origintrail-official/dkg-node-ui test, and Playwright dev-server checks while pnpm --filter @origintrail-official/dkg-node-ui run build:ui fails under Vite 8 config or bundling changes.
Suggested direction
Add CI or documented validation for the Node UI production bundle after this major Vite/plugin-react upgrade, ideally the exact build:ui command used by the release/runtime build.
Confidence note
I cannot see PR check results from the diff, but the repository workflow context shows the in-repo CI path intentionally skips this bundle.
For Agents
Look at packages/node-ui/package.json, packages/node-ui/vite.config.ts, and .github/workflows/ci.yml. Preserve the existing fast package-build behavior if needed, but add a targeted validation for the production Vite bundle, such as running pnpm --filter @origintrail-official/dkg-node-ui run build:ui on dependency-update PRs or in the node-ui lane. The proof should fail if Vite 8 cannot produce dist-ui.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
33f382f to
c726e29
Compare
| "@types/react": "^19.0.0", | ||
| "@types/react-dom": "^19.0.0", | ||
| "@vitejs/plugin-react": "^4.4.0", | ||
| "@vitejs/plugin-react": "^6.0.3", |
There was a problem hiding this comment.
🟡 Issue: Centralize the workspace toolchain versions instead of adding more divergent specifiers
What's wrong
This PR upgrades the same build/test toolchain in multiple package manifests, but it leaves each workspace expressing the versions differently. That is not just lockfile churn: it increases the number of places future maintainers must remember to update and makes it harder to tell whether a workspace intentionally differs or simply drifted.
Example
A future Vite or Vitest bump now has to rediscover several independent specifier styles: ^8.1.0, ^8, exact 4.1.9, and existing ^4.0.18 ranges. That makes the lockfile the only place where the actual toolchain version is coherent.
Suggested direction
Introduce a single dependency-version policy for the shared toolchain, then reference it from each workspace instead of hand-maintaining local semver ranges.
Confidence note
The repo does not currently use pnpm catalogs, so the exact centralization mechanism is a policy choice; the duplicated and divergent version specifiers are visible in the changed manifests.
For Agents
Look at pnpm-workspace.yaml, root package.json, and the changed package manifests. Preserve the selected resolved versions, but move shared build/test tool versions such as vite, @vitejs/plugin-react, vitest, @vitest/coverage-v8, and @types/node behind one workspace-level policy, preferably pnpm catalogs if acceptable for this repo. Regenerate pnpm-lock.yaml and verify the lockfile still resolves the same toolchain versions.
There was a problem hiding this comment.
🟡 Issue: Centralize the shared toolchain versions instead of adding more per-package literals
What's wrong
This PR updates workspace-wide build/test tooling by editing individual package manifests directly. In a monorepo, that makes dependency policy harder to audit because the intended Vite/React plugin/Vitest/Node-types version is no longer expressed once; it is inferred from several duplicated literals with different specificity. The implementation works as dependency metadata, but structurally it increases drift risk and makes future toolchain upgrades noisier than necessary.
Example
A future Vite/plugin/Vitest maintenance bump now has to rediscover and edit several package manifests with slightly different range styles (^8, ^8.1.3, ^6, ^6.0.3, exact 4.1.10). That keeps the lockfile coherent today, but leaves the workspace dependency policy encoded as scattered literals rather than one obvious source of truth.
Suggested direction
Use a pnpm catalog in pnpm-workspace.yaml for the shared build/test toolchain, then reference it from package manifests with catalog:. That would make this upgrade a single policy change instead of a set of hand-synchronized manifest edits, and it would remove the inconsistent range styles introduced here.
For Agents
Look at the package manifests touched by this PR plus pnpm-workspace.yaml. Preserve the resolved versions, but move shared toolchain dependencies such as Vite, @vitejs/plugin-react, Vitest, coverage, and Node types behind a central pnpm catalog or another existing workspace-level version policy. Prove the manifest change with pnpm install --lockfile-only and a representative filtered install/build.
There was a problem hiding this comment.
🟡 Issue: Upgrade the frontend toolchain as a coherent unit
What's wrong
The PR performs a major Vite/plugin-react bump but leaves coupled test-tool declarations on the old 4.0.x baseline. That creates dependency drift in the package boundary: package.json no longer tells readers which test/build stack this package is meant to run, and future updates can easily move one part without the others. The same root cause recurs at packages/graph-viz/package.json line 78 and packages/node-ui/package.json line 63.
Example
A future maintainer reading packages/network-sim/package.json sees Vite 8 but Vitest/Coverage 4.0.18, while the lockfile actually installs Vitest/Coverage 4.1.10. The dependency graph's intended baseline is split between manifests and lockfile resolution.
Suggested direction
Make the manifests describe the same toolchain baseline the lockfile installs. The cleaner move is a shared workspace catalog or a synchronized bump of Vite, @vitejs/plugin-react, Vitest, and @vitest/coverage-v8 across the affected packages, instead of relying on the lockfile to paper over stale direct ranges.
Confidence note
This is based on the manifests and lockfile diff; it does not require assuming the dependency versions are behaviorally broken.
For Agents
Review the Vite/Vitest/Coverage/React plugin versions as one frontend toolchain. Update the direct manifest ranges together, or introduce a pnpm catalog/shared dependency policy so package.json files declare the intended baseline. Preserve the current resolved versions, then run install/typecheck/tests for graph-viz, network-sim, and node-ui.
There was a problem hiding this comment.
🟡 Issue: The Vite 8 upgrade is not validated by production build checks
What's wrong
This PR changes the frontend build toolchain from Vite 6 to Vite 8 across packages, but the existing validation I found does not exercise the production Vite build paths. That leaves a realistic gap because dependency-only build-tool upgrades often fail in production bundling while unit tests and dev-server e2e still pass.
Example
A regression in Vite 8 production bundling, CSS processing, or plugin-react's build integration could still pass the current Vitest/dev-server checks while pnpm sim:build or pnpm --filter @origintrail-official/dkg-node-ui build:ui fails.
Suggested direction
Add CI or documented validation that runs the affected Vite production build scripts, not just Vitest or Playwright dev-server coverage.
Confidence note
I did not run the builds in this read-only review environment; this is based on the package scripts and CI workflow in the diff context.
For Agents
Look at the CI workflow and package scripts for graph-viz, network-sim, and node-ui. Preserve the existing unit/e2e test coverage, but add a PR validation step that runs the Vite production builds touched by this dependency bump: network-sim build, graph-viz demo:build, and node-ui build:ui or an existing aggregate that includes them. The proof should fail if Vite 8 cannot produce the bundle.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
c726e29 to
e6fb66c
Compare
| }, | ||
| "devDependencies": { | ||
| "vitest": "4.0.18" | ||
| "vitest": "4.1.9" |
There was a problem hiding this comment.
🟡 Issue: Don’t hide the workspace Vitest baseline in one devnet package
What's wrong
This adds a one-off exact version in a small devnet package while the same tool remains declared with broader, older ranges throughout the monorepo. That is dependency-policy drift: the lockfile carries a workspace-wide upgrade, but the manifest that explains why is local and easy to miss.
Example
A maintainer grepping package manifests would see most packages still on ^4.0.18, but a fresh lockfile update is constrained by devnet/edge-update-flow's exact 4.1.9 pin. That makes the intended Vitest baseline unclear.
Suggested direction
Make the Vitest upgrade explicit at the workspace level instead of using an exact pin in this one package. A pnpm catalog for shared toolchain versions would also solve the repeated Vite/Vitest/Node type version drift in this PR.
For Agents
Inspect all workspace package.json files that declare vitest and @vitest/coverage-v8. Preserve the intended Vitest 4.1.9 resolution, but express it through a single visible policy: either align the package specifiers or introduce a pnpm catalog/shared dependency policy and point packages at it. Verify pnpm install --lockfile-only does not churn unrelated entries afterward.
There was a problem hiding this comment.
🟡 Issue: Keep the devnet Vitest version policy consistent
What's wrong
This introduces a one-off dependency policy in a workspace where the surrounding devnet packages all use the same Vitest range. The lockfile already resolves the range to 4.1.9, so the exact pin adds maintenance state without simplifying anything.
Example
A future Vitest patch can be picked up by every other devnet through the shared ^4.0.18 policy, while edge-update-flow stays frozen until someone notices this one exception.
Suggested direction
Either keep this package on the same range policy as the rest of the devnet packages, or deliberately bump all Vitest manifest specifiers together. Avoid making one devnet carry an exact pin unless there is a documented package-specific reason.
For Agents
Review all vitest devDependency specifiers in root and devnet/*/package.json; preserve the resolved lockfile version if desired, but make the manifest policy consistent. A lockfile-only diff should prove the same Vitest version is installed after the change.
There was a problem hiding this comment.
🟡 Issue: Avoid making one devnet fixture a special-case Vitest pin
What's wrong
This introduces a single-package exception in a set of otherwise uniform devnet manifests. Dependency policy becomes harder to reason about because the lockfile upgrades the whole workspace, but only this fixture records the new exact version in its manifest.
Example
Running pnpm --filter @origintrail-official/dkg-devnet-edge-update-flow update vitest will behave differently from the neighboring devnet packages because this one is exact-pinned while the rest use the shared caret policy.
Suggested direction
Either align this package with the existing devnet caret range, or centralize/pin Vitest for the whole workspace. The current one-off exact pin reads like accidental dependency policy drift.
For Agents
Inspect all devnet package.json files and decide on one Vitest version policy. Preserve the resolved Vitest version if intended, but express it consistently, preferably via a shared workspace-level mechanism or by updating all devnet manifests the same way.
There was a problem hiding this comment.
🟡 Issue: Declare the Vitest upgrade policy instead of letting the lockfile carry it
What's wrong
This adds a new one-off exact Vitest pin while the rest of the workspace still advertises the older broad range. The lockfile then upgrades Vitest and coverage across many unrelated importers, so the repository’s actual test-toolchain version is implicit and harder to maintain. Future dependency refreshes will be noisy and reviewers will have to infer intent from lockfile churn rather than from a clear version policy.
Example
A maintainer looking at devnet/_bootstrap/package.json still sees vitest ^4.0.18, while pnpm-lock.yaml resolves that same specifier to 4.1.10. It is not clear whether 4.1.10 is a deliberate workspace-wide toolchain target or incidental resolver drift from this one exact pin.
Suggested direction
Pick one dependency-management shape: either centralize shared test-tool versions with a pnpm catalog/override and update all Vitest-related specs together, or keep this package-local pin from causing a repo-wide lockfile upgrade. Avoid mixing one exact pin, many loose 4.0-range manifests, and a lockfile-wide 4.1 resolution.
For Agents
Review all vitest/@vitest/coverage-v8 declarations across package.json files and pnpm-lock.yaml. Preserve the resolved behavior, but express the intended Vitest version policy in manifests or a pnpm catalog/central dependency policy. If only edge-update-flow needs 4.1.10, regenerate the lockfile without upgrading unrelated importers. Verify with pnpm install --frozen-lockfile and a representative test command.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
e6fb66c to
681c09a
Compare
| "devDependencies": { | ||
| "@origintrail-official/dkg": "workspace:*", | ||
| "@types/node": "^22", | ||
| "@types/node": "^26", |
There was a problem hiding this comment.
🟡 Issue: Keep Node types aligned with the repo runtime
What's wrong
The dependency update moves the ambient Node type surface to 26 while the repository still declares Node 22 as the version used by CI and release workflows. That makes the type system less trustworthy because it no longer models the runtime boundary maintainers actually operate against.
Example
A developer can now write code against Node 26-only globals or API shapes and get a clean typecheck, while CI and release workflows still run under Node 22 from .nvmrc. The type boundary no longer documents the runtime the repo actually supports.
Suggested direction
Treat the Node version as a single compatibility boundary. If the project still runs on Node 22, keep @types/node on the Node 22 line. If the goal is to move to Node 26, make that explicit by updating .nvmrc and the workflow/runtime policy in the same change.
For Agents
Look at package.json, packages/evm-module/package.json, and .nvmrc. Keep the runtime support unchanged unless the PR intentionally upgrades it. Either keep @types/node aligned to Node 22, or update the repo runtime policy in .nvmrc/CI together and verify typecheck/build under that runtime.
There was a problem hiding this comment.
🟡 Issue: Keep Node type declarations aligned with the repo runtime boundary
What's wrong
This makes the type boundary looser than the runtime boundary. Type declarations are part of the maintainability contract for a TypeScript repo; letting them drift ahead of the Node version the workspace actually runs on encourages accidental use of APIs the project has not declared support for.
Example
A future use of a Node API added after Node 22 would type-check against @types/node@26, but the repo's documented/CI Node line remains 22, so the real runtime boundary is no longer visible from the types.
Suggested direction
Make the Node boundary explicit and single-sourced: either revert the Node typings to the Node 22 line used by .nvmrc, or deliberately move the repo's Node version contract to 26 together with these type bumps.
For Agents
Look at root package.json, packages/evm-module/package.json, and .nvmrc. Preserve the intended runtime support, then either keep @types/node on the Node 22 type line or update .nvmrc/CI/runtime metadata to Node 26 in the same PR. A type-check/build should prove the chosen boundary is consistent.
There was a problem hiding this comment.
🟡 Issue: Make the Node runtime/type baseline explicit before widening the typings
What's wrong
Bumping root typings to Node 26 widens the compile-time API surface without showing the corresponding runtime contract. That weakens the type boundary: TypeScript becomes a less reliable signal for what APIs the workspace is actually allowed to use, and the same decision is repeated locally in packages/evm-module.
Example
A developer can now add code that type-checks only because Node 26 typings are available, while a package or script may still be expected to run on Node 20/22. The problem is the unclear boundary: readers cannot tell whether Node 26 APIs are allowed or whether this is only a dev dependency refresh.
Suggested direction
Declare the supported Node baseline centrally, then align @types/node to that policy. If the project now intentionally requires Node 26 APIs, make that visible with engines and consistent package metadata; otherwise keep typings on the supported runtime major.
Confidence note
This is a maintainability/type-boundary concern, not a claim that current code already uses a Node 26-only API. The repo context shown here does not expose a central runtime engine declaration that would make the new type baseline explicit.
For Agents
Inspect the root package policy and packages/evm-module/package.json. Preserve the intended type upgrade, but declare the supported Node runtime baseline in one canonical place and align @types/node to that baseline through the same dependency-management mechanism used for shared tooling. Add a typecheck/install verification step after regenerating the lockfile.
There was a problem hiding this comment.
🟡 Issue: Keep Node typings aligned with the repo's runtime policy
What's wrong
The PR upgrades the type surface to Node 26 while the repository still advertises and runs against Node 22. That weakens the platform contract: types stop being a reliable description of the runtime, and future code can silently depend on APIs the canonical runtime does not provide.
Example
A future change can import or call a Node 26-only API and still typecheck locally, while the repo's canonical runtime/build lane remains Node 22. That makes the TypeScript boundary describe a different platform than the one contributors and CI are actually using.
Suggested direction
Treat this as a boundary cleanup, not just a package bump. Either keep @types/node on the Node 22 line, or make Node 26 the explicit repo runtime by updating .nvmrc, CI, release tooling, and package engines in the same change.
For Agents
Look at root package.json, packages/evm-module/package.json, .nvmrc, and workflows that read .nvmrc. Preserve the intended runtime, but make the Node version contract single-source: either keep typings on Node 22, or intentionally move the runtime policy to Node 26 by updating .nvmrc/CI/package engines together. Add a small compile check that proves the selected @types/node version matches the supported Node runtime.
There was a problem hiding this comment.
🟡 Issue: Keep Node ambient types aligned with the repo runtime contract
What's wrong
The PR upgrades the ambient Node types to 26 while the repository still signals Node 22 as the workspace runtime. That makes the type system less useful as a boundary: it can now bless APIs that are not guaranteed by the runtime this repo tells contributors to use.
Example
A future change can compile after using a Node 26-only global/API because @types/node@26 exposes it, even though the workspace still advertises Node 22 via .nvmrc. The type boundary no longer models the supported runtime.
Suggested direction
Treat @types/node as part of the runtime contract, not just a floating dev dependency. If the repo still supports or pins Node 22, keep the Node 22 types; if Node 26 is intended, make that explicit in .nvmrc/engines/CI and update all related comments/docs together.
For Agents
Check the root runtime policy (.nvmrc, CI images, docs) before changing Node ambient types. Either bump the runtime contract everywhere to Node 26, or keep @types/node on the supported Node major. Verify with a typecheck on the intended Node lane.
There was a problem hiding this comment.
🟡 Issue: Keep Node type declarations aligned with the repo runtime
What's wrong
The PR upgrades the type surface to Node 26 while the repo still declares Node 22 as the development/runtime baseline. That makes the TypeScript boundary misleading: reviewers and contributors can no longer tell from the canonical config which Node APIs are actually safe to use. The same pattern recurs in packages/evm-module/package.json line 47.
Example
A contributor on the documented Node 22 runtime can now write code that type-checks against Node 26-only globals or API shapes because the workspace type surface no longer matches the runtime baseline.
Suggested direction
Treat the Node version as one workspace-level contract. Either leave @types/node on 22 here and in evm-module, or move the whole repo runtime policy to the version whose types are being adopted.
For Agents
Keep the runtime and type boundary aligned. Check .nvmrc, README prerequisites, CI setup-node usage, root package.json, and packages/evm-module/package.json. Either keep @types/node on the Node 22 line or update the repo's runtime policy/docs/CI together. A typecheck on the documented runtime should prove the boundary is coherent.
There was a problem hiding this comment.
🟡 Issue: Node 26 typings no longer match the Node 22 runtime contract
What's wrong
The repository still advertises and runs against Node 22, but the type surface now represents Node 26. That weakens the type checker as a runtime compatibility gate: code can compile against APIs or signatures that are not available in the supported runtime.
Example
A future change could use an API that exists in @types/node@26 but is absent from the repository's Node 22 runtime. TypeScript would accept it, CI would still install Node 22 from .nvmrc, and the released CLI/node code could fail at runtime when that path executes.
Suggested direction
Keep @types/node on the same major version as the supported Node runtime, or explicitly raise the repository runtime version everywhere that consumes .nvmrc.
Confidence note
The diff does not add code that already calls a Node 26-only API, so this is an integration contract risk rather than an observed runtime failure.
For Agents
Align Node typings with the actual supported runtime. Check root package.json, packages/evm-module/package.json, .nvmrc, and CI setup-node usage. Either keep @types/node on the Node 22 line or update the runtime contract and CI to Node 26. Add a small compile/runtime guard if a Node-version-specific API is intentionally introduced.
Make the Node runtime boundary explicit with the Node type bump
What's wrong
The PR moves the ambient Node type surface to Node 26 without declaring the corresponding runtime floor. That makes the type boundary looser than the runtime contract and leaves future contributors guessing which Node APIs are safe to use. This is a maintainability problem because the repository policy lives in incidental dependency choices rather than in package metadata.
Example
After this bump, a new helper can type-check against Node 26-only APIs because the ambient Node types expose them. Nothing in the package metadata tells maintainers or consumers whether running under Node 20 or Node 22 is still supported.
Suggested direction
Couple the @types/node major bump with an explicit Node support policy, preferably in engines.node for the root and any published workspaces. If the repo still supports an older Node major, keep the Node typings on that minimum supported major instead of widening the ambient API surface to 26.
Confidence note
If the project intentionally now requires Node 26 or a newer Node floor, the same concern still applies: that policy should be declared in package metadata rather than only implied by typings and tool dependencies.
For Agents
Inspect CI/runtime requirements and published package support policy. Either add explicit engines.node entries at the root and publishable packages that match the intended Node floor, or keep @types/node aligned to the minimum supported runtime major. Preserve existing build/test behavior and verify package metadata checks still pass.
There was a problem hiding this comment.
🟡 Issue: Keep Node type definitions aligned with the workspace runtime boundary
What's wrong
@types/node is part of the TypeScript boundary for scripts and packages. Moving it to Node 26 while the workspace still advertises Node 22 makes the supported runtime implicit and easier to violate accidentally.
Example
A later script can start using a Node 26-only API and still typecheck because the workspace types expose it, even though contributors and CI are guided to Node 22 by .nvmrc.
Suggested direction
Either keep @types/node on the Node major the repo actually runs, or make the Node runtime upgrade explicit in the same PR. The maintainable shape is one clear Node baseline, not type definitions that silently move ahead of the runtime contract.
Confidence note
This assumes the repository still intends .nvmrc value 22 to describe the supported local/CI runtime; I did not see an engines field overriding that in the changed manifests.
For Agents
Check the intended Node runtime baseline. If it remains Node 22, keep @types/node on the matching major across root and package manifests. If the PR intentionally raises the runtime floor, update .nvmrc and any package engines policy in the same change so the type boundary and runtime boundary stay aligned.
There was a problem hiding this comment.
🟡 Issue: Keep Node types aligned with the repo runtime
What's wrong
The dependency bump changes the TypeScript boundary without changing the runtime boundary. That makes the workspace easier to accidentally type-check against APIs that are not part of the declared Node version, and it splits one invariant across unrelated files.
Example
A package can now type-check against Node 26 ambient APIs while CI/developers are still directed to Node 22 via .nvmrc. Even if no current code uses those APIs, the type boundary now advertises a different runtime than the repo actually standardizes on.
Suggested direction
Treat the Node version as one explicit workspace contract. If the intended runtime is still Node 22, keep @types/node on 22. If the intended runtime is Node 26, update the canonical runtime declaration instead of only changing ambient types.
For Agents
Check the root runtime policy first: .nvmrc, CI setup-node usage, and any package publish/runtime expectations. Either keep @types/node aligned to Node 22 or explicitly move the runtime contract to Node 26 with the matching repo metadata. Verify with the existing typecheck/build flow under the declared runtime.
There was a problem hiding this comment.
🟡 Issue: Keep Node typings aligned with the repo runtime
What's wrong
The PR upgrades the type boundary to Node 26 without moving the repo's runtime boundary. That weakens TypeScript as a guardrail and makes the workspace's supported Node version harder to reason about.
Example
A future change could call a Node 26-only API and pass TypeScript because the workspace is typed as Node 26, even though local/CI execution is still on the repo's Node 22 lane.
Suggested direction
Either keep @types/node on the Node 22 major while .nvmrc remains 22, or make this a real Node 26 toolchain migration by updating the runtime pin and CI/docs in the same PR.
For Agents
Review package.json, packages/evm-module/package.json, .nvmrc, and CI setup-node usage. Preserve the intended toolchain upgrade, but make the Node boundary explicit: either keep @types/node on the runtime major or bump the runtime policy and docs together. Add/adjust a version-policy check if one exists.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
3 times, most recently
from
af57bdd to
208b5bf
Compare
| "tsup": "^8.4.0", | ||
| "typescript": "^5.7.0", | ||
| "vite": "^6.4.2", | ||
| "vite": "^8.1.3", |
There was a problem hiding this comment.
🟡 Issue: Vite 8 raises the effective Node floor without updating the repo runtime contract
What's wrong
The changed dependency makes Vite-based workspaces require a newer Node patch level than the repository advertises. Because the repo still points users and CI at a broad Node 22, some supported-looking Node 22 installations can no longer reliably build the affected packages.
Example
A contributor or auto-update environment on Node 22.10 follows the repo’s 22 runtime hint, installs the new lockfile, then runs pnpm --filter @origintrail-official/dkg-graph-viz demo:build or pnpm run build:runtime; Vite 8 is outside its declared engine range and the UI/graph build is unsupported or can fail. Expected behavior is that the repo’s declared Node floor matches the upgraded tooling.
Suggested direction
Align the runtime contract with the new toolchain before merging: pin .nvmrc/docs/CI to a compatible minimum such as 22.12 or higher, or defer the Vite 8 upgrade until the project is ready to drop older Node 22.x environments.
Confidence note
CI that resolves .nvmrc value 22 to the latest 22.x may still pass; the break is for callers or update jobs running an older Node 22.x that the repo still appears to allow.
For Agents
Look at .nvmrc, root/package workflow Node setup, and the Vite consumers in packages/graph-viz, packages/network-sim, and packages/node-ui. Either keep Vite/plugin-react on versions compatible with the supported Node 22 range, or explicitly raise the repo Node contract to at least 22.12 and prove install plus UI/graph builds under that minimum.
There was a problem hiding this comment.
🟡 Issue: Vite 8 is resolved against a Vitest release that still declares Vite 7.3.2
What's wrong
The changed Vite 8 dependency causes packages that also run Vitest to resolve Vitest against a Vite version outside Vitest's own peer contract. That makes the test/build toolchain rely on an unsupported integration boundary, which can break CI or release workflows even when the lockfile installs.
Example
With this lockfile, pnpm --filter @origintrail-official/dkg-node-ui test runs Vitest 4.1.10 with Vite 8.1.3 even though Vitest's peer contract in the lockfile only accepts Vite 7.3.2. In strict peer installs this can fail dependency installation; otherwise Vitest may execute against unsupported Vite APIs. Expected behavior is that the resolved Vite version satisfies Vitest's declared peer range.
Suggested direction
Align the Vite and Vitest major versions instead of mixing Vite 8 with a Vitest lock entry that still declares Vite 7.3.2 as its supported peer.
Confidence note
The lockfile shows the peer contract mismatch directly; the exact runtime symptom should be verified by running the affected package test/build commands because pnpm may only warn for optional peer mismatches unless strict peer checking is enabled.
For Agents
Check the Vite/Vitest alignment in packages/graph-viz, packages/network-sim, packages/node-ui, and the root pnpm overrides. Either keep Vite on the supported 7.3.2 line for the current Vitest release, or move Vitest/coverage to a release whose peer contract explicitly accepts Vite 8. Prove the fix with pnpm install --frozen-lockfile and the affected test/build commands for those packages.
There was a problem hiding this comment.
🟡 Issue: Centralize the build/test toolchain instead of letting each manifest drift
What's wrong
This PR updates major build/test tooling through scattered manifest edits with different range precision and unresolved peer ownership. That makes the actual toolchain a lockfile side effect rather than a clear workspace contract, which is brittle for future upgrades and hard for maintainers to reason about.
Example
A future package install can keep the manifest text unchanged but reshuffle the peer slot for Vite depending on which nearby transitive dependency happens to provide esbuild; readers then have to inspect pnpm-lock.yaml to know which build toolchain a package is actually using.
Suggested direction
Introduce a single workspace-level version policy for the upgraded toolchain, then have the package manifests reference it consistently. If Vite 8 needs an esbuild peer in this repo, make that dependency explicit rather than letting pnpm satisfy it differently per importer.
For Agents
Look at all changed package manifests plus the root dependency policy. Preserve the intended upgrades, but move shared build/test tool versions (vite, @vitejs/plugin-react, vitest, @vitest/coverage-v8, @types/node, and any required peer such as esbuild) behind one workspace-level source of truth, such as pnpm catalogs or consistent root/package specs. Verify the lockfile resolves one intentional toolchain shape across graph-viz, network-sim, node-ui, and devnet tests.
There was a problem hiding this comment.
🟡 Issue: Vite 8 narrows the supported Node 22 range without updating the repo runtime pin
What's wrong
The dependency change makes Vite-based package scripts require a newer Node patch level than the repository currently advertises through .nvmrc. That can break builds/tests for users or runners that are correctly following the repo's Node 22 pin but are on Node 22.5-22.11.
Example
A developer or CI runner already on Node 22.11 can satisfy the repo's .nvmrc value of 22, but Vite-backed commands such as pnpm --filter @origintrail-official/dkg-node-ui run build:ui or graph-viz/network-sim Vite scripts are now outside Vite's supported engine range. Expected behavior is that the repo's pinned Node version remains sufficient for these package scripts.
Suggested direction
If Vite 8 is required, update the repo's Node contract to a concrete compatible version such as 22.12+ and keep CI/local docs aligned. Otherwise stay on a Vite version compatible with the currently advertised Node 22 range.
Confidence note
This depends on whether the project still intends to support all Node 22 patch releases. The repo pins .nvmrc to 22 and local comments reference Node 22.5-23.x, while the new Vite toolchain requires at least Node 22.12.
For Agents
Check the Node runtime contract in .nvmrc, CI setup-node usage, and Vite-backed packages (graph-viz, network-sim, node-ui). Either pin/declare Node 22.12+ or choose tool versions compatible with the intended Node 22 range. Prove the fix with an install plus at least one Vite build/test command under the documented Node version.
There was a problem hiding this comment.
🟡 Issue: Vite 8 raises the actual Node floor above the documented Node 22+ contract
What's wrong
This upgrade changes the effective development/build contract from “Node.js 22+” to “Node.js 22.12+ or 20.19+” for the Vite-backed workspaces, but the repo still tells users and automation that any Node 22 is acceptable. That creates an integration break for valid documented environments in the Node 22.0-22.11 range.
Example
A developer following the documented Node.js 22+ requirement with Node 22.10 or 22.11 can now hit engine rejection in stricter installs, or Vite/plugin runtime failures, when running workspace commands such as pnpm --filter @origintrail-official/dkg-node-ui build:ui or pnpm --filter @origintrail-official/dkg-network-sim build. Those Node versions satisfy the repo docs but not the new Vite 8 toolchain contract.
Suggested direction
Align the declared project Node requirement with the new toolchain, or choose dependency versions whose engine ranges still match the existing Node 22+ support promise.
Confidence note
The dependency engine requirement is explicit in the updated lockfile, but whether it hard-fails depends on the caller's package-manager engine settings and exact Node patch version.
For Agents
Look at the Vite 8 / @vitejs/plugin-react 6 upgrades in graph-viz, network-sim, and node-ui. Either preserve the documented Node 22+ compatibility by staying on a Vite/plugin line that supports all Node 22 patches, or update the repo/runtime contract to require Node >=22.12 and make .nvmrc/docs/CI explicit. Prove the fix by installing and running the affected Vite build commands on the lowest supported Node version.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
2 times, most recently
from
11a0bb9 to
b6efe8b
Compare
| "@types/react-dom": "^19", | ||
| "@types/three": "^0.183.1", | ||
| "@vitejs/plugin-react": "^4", | ||
| "@vitejs/plugin-react": "^6", |
There was a problem hiding this comment.
🟡 Issue: Centralize the toolchain version bumps instead of adding more per-package drift
What's wrong
This PR upgrades shared toolchain packages by editing individual workspace manifests with different range styles and leaves many related manifests on older-looking ranges while the lockfile resolves them to newer versions. That makes the dependency model less legible: the source of truth becomes split between leaf manifests, root overrides, and the generated lockfile. The cleaner structure is to make the intended toolchain baseline explicit once, then have workspaces consume it consistently.
Example
A future pnpm update can now move node-ui to any Vite 8.x, keep network-sim on a different floor, and leave most Vitest manifests advertising the old ^4.0.18 baseline even though the lockfile currently resolved 4.1.10. Maintainers have to read the lockfile to infer the intended toolchain version.
Suggested direction
Use one canonical version declaration for shared dev tooling, preferably a pnpm catalog given this repo already standardizes on pnpm 10. At minimum, make the manifest ranges consistent across all workspaces touched by this lockfile refresh and align the existing Vite override/dependency policy with the Vite 8 baseline.
For Agents
Look at the shared dev-tool dependencies in package.json, packages//package.json, and devnet//package.json. Preserve the intended upgrades to Node types, Vite, plugin-react, and Vitest, but move their versions into a single policy surface such as pnpm catalogs or consistent workspace-wide ranges, then update affected manifests to reference that policy. Verify with pnpm install --lockfile-only and a recursive dependency listing that only the intended versions resolve.
There was a problem hiding this comment.
🟡 Issue: Vite 8 raises the required Node version beyond the repo's Node 22 contract
What's wrong
The changed Vite dependency now requires Node ^20.19.0 || >=22.12.0, but the workspace still advertises the broad Node 22 line via .nvmrc. That can make supported Node 22.x environments below 22.12 fail when they build or run the UI tooling.
Example
On a developer or release environment using Node 22.11 from the existing .nvmrc line, pnpm --filter @origintrail-official/dkg-node-ui run build:ui will invoke Vite 8, whose own engine range excludes that runtime. Expected: the repo's Node 22 setup remains buildable, or the repo explicitly pins a compatible Node version such as 22.12+.
Suggested direction
Update the repo's Node version contract to a concrete compatible version, or avoid the Vite 8/plugin-react 6 upgrade until the supported Node floor is raised.
Confidence note
This depends on whether the project still intends to support the whole Node 22 line implied by .nvmrc rather than only current/latest Node 22 releases.
For Agents
Look at the Vite 8 upgrades in packages/node-ui, packages/network-sim, and packages/graph-viz, plus the root .nvmrc and workflows. Either pin the repo runtime to a Vite-compatible Node version or keep Vite/plugin-react on versions compatible with the current Node contract. Prove the fix by running install and the UI build under the Node version advertised by .nvmrc.
Centralize the shared toolchain version policy instead of scattering new ranges
What's wrong
The PR updates the same toolchain family across several workspace packages, but each manifest now expresses the version intent differently. That is maintainability drift: reviewers and future dependency PRs must reason about lockfile side effects and local range choices instead of a single workspace-level toolchain policy.
Example
The next Vite or Vitest upgrade has to infer intent from several package manifests plus pnpm-lock.yaml: is the project policy ^8, ^8.1.3, or the exact locked version? That ambiguity is small today, but it scales poorly as more packages grow their own toolchain pins.
Suggested direction
Use one canonical version policy for shared build/test tooling, for example pnpm catalogs or another repo-standard dependency policy mechanism, and have package manifests reference it consistently. This would let the PR say "the workspace is on Vite 8.1.3 / plugin-react 6.0.3 / Vitest 4.1.10" once instead of encoding that policy slightly differently in each package.
For Agents
Review all changed package.json files for Vite, @vitejs/plugin-react, Vitest, @vitest/coverage-v8, and @types/node. Preserve resolved versions, but move the shared toolchain versions into one policy location, such as pnpm catalogs or a documented root-level version block, then reference that from package manifests. Verify pnpm install --frozen-lockfile keeps the same resolved graph.
Vite 8 production bundle path is not validated
What's wrong
This PR changes the toolchain that produces the shipped Node UI static assets, but the normal PR validation path appears to skip that production bundle. Existing Vitest and Playwright coverage can pass while the release-facing vite build path is broken.
Example
A Vite 8 production-build regression in pnpm --filter @origintrail-official/dkg-node-ui build:ui would not be caught by the existing PR build, because CI restores the package build artifact and never builds dist-ui on the changed Vite version.
Suggested direction
Add a targeted build smoke for the Vite-backed UI bundle, or provide explicit validation evidence that the bundle still builds under Vite 8.
For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the existing fast package-build/test lanes, but add targeted validation for the changed Vite production path, such as a CI step or documented PR evidence running pnpm --filter @origintrail-official/dkg-node-ui build:ui; consider including packages/network-sim build and packages/graph-viz demo:build if those Vite 8 paths are intended to be covered too.
There was a problem hiding this comment.
🔴 Bug: Vite 8 narrows the supported Node 22 range below the documented contract
What's wrong
This dependency bump makes the runtime UI build depend on Vite 8, but Vite 8 requires Node ^20.19.0 or >=22.12.0. The repo still tells users and CI to use generic Node 22+, so Node 22.0 through 22.11 remain documented as valid even though the changed build toolchain no longer supports them. That can block runtime/package builds and auto-update style source builds for users on an otherwise documented Node 22 installation.
Example
A user following the README on Node 22.10.0 is still on "Node.js 22+", but pnpm --filter @origintrail-official/dkg-node-ui run build:ui now invokes Vite 8, whose supported engine range starts at Node 22.12.0. Expected: documented Node 22+ users can build the runtime UI. Current: supported-but-older Node 22 installations fall outside the toolchain's engine contract and can fail at install/build time.
Suggested direction
Align the dependency bump with the supported Node contract: downgrade/hold Vite for Node 22.0+ compatibility, or update .nvmrc, README prerequisites, package engines, and CI/publish setup to require a concrete Node version that satisfies Vite 8.
Confidence note
I did not run the build under an older Node 22.x binary in this read-only sandbox; this is based on the new dependency engine metadata in the lockfile and the repo's documented Node 22+ support contract.
For Agents
Check the Vite/plugin-react bumps in packages/node-ui, packages/graph-viz, and packages/network-sim plus pnpm-lock.yaml. Either keep the Vite toolchain on a version compatible with all documented Node 22.x releases, or change the public/CI contract to a concrete minimum like >=22.12.0 and add an engines/preflight check that proves pnpm build:runtime fails fast with a clear message on older 22.x.
Centralize the Vite toolchain version instead of scattering mixed ranges
What's wrong
The PR updates the frontend toolchain in three package manifests with slightly different range contracts and leaves related root dependency policy on the old Vite major. That makes the toolchain ownership blurry and increases future lockfile churn.
Example
A later lockfile refresh can legally resolve node-ui to a newer Vite 8 minor than network-sim/graph-viz, even though these packages are supposed to share the same frontend toolchain generation.
Suggested direction
Use one workspace-level source of truth for Vite/plugin-react versions, or at least use the same version range shape across the packages touched here. Also revisit the root Vite override so dependency policy does not point at the previous major line while direct deps move to Vite 8.
Confidence note
This is based on manifest structure and lockfile resolution only; there may be an external dependency-management policy not visible in the diff.
For Agents
Review the workspace dependency policy for Vite and React plugin versions. Keep behavior unchanged, but express the Vite 8 toolchain through one consistent range or a shared pnpm catalog/override, and update obsolete Vite 7 policy entries if they are no longer canonical.
Node UI production Vite build is not validated in PR CI
What's wrong
This dependency change affects the production dashboard bundle, but the existing PR checks appear to skip that exact vite build path. The PR still gets coverage for package builds, Vitest, and the Playwright dev server, but not for the static dist-ui artifact that release/publish later produces.
Example
A minimal validation that currently is not represented in PR CI would be pnpm --filter @origintrail-official/dkg-node-ui run build:ui; this is the command most directly affected by the Vite 8 upgrade.
Suggested direction
Add a targeted CI check or documented validation evidence for @origintrail-official/dkg-node-ui's build:ui path when bumping Vite/plugin-react, ideally without replacing the existing package-build optimization.
For Agents
Look at packages/node-ui/package.json, scripts/build.mjs, and .github/workflows/ci.yml. Preserve the existing fast build:packages behavior, but add a PR-visible validation step or targeted job that runs the Node UI production bundle command after the Vite/plugin-react upgrade, and make it fail on build errors.
There was a problem hiding this comment.
🟡 Issue: Centralize the shared toolchain version policy instead of encoding divergent ranges
What's wrong
This PR is a cross-workspace toolchain upgrade, but the changed manifests encode the same dependency family with different range styles and floors. That makes package.json stop being a clear source of truth: readers have to infer the real policy from the lockfile, and future dependency updates can drift per package for reasons unrelated to the package itself.
Example
A future pnpm update vite or package-local install can move node-ui to a newer Vite 8 minor while graph-viz/network-sim stay bounded by a different floor; edge-update-flow is the only devnet package that cannot float within Vitest 4. The lockfile hides that today, but the manifests now encode several different policies for the same shared toolchain.
Suggested direction
Use a single workspace-level version source for these toolchain dependencies, such as pnpm catalogs, then reference it from each package. If catalogs are too large a change for this PR, align the changed ranges consistently so the manifests express one upgrade policy instead of several package-local variants.
For Agents
Look at root package.json, pnpm-workspace.yaml, and the changed package manifests. Preserve the intended Vite/Vitest/@types/node upgrades, but move shared toolchain versions into one policy: preferably pnpm catalogs for vite, @vitejs/plugin-react, vitest, @vitest/coverage-v8, and @types/node, or at least align all manifest ranges exactly. Verify with pnpm install --lockfile-only that the lockfile remains stable.
The Vite 8 production UI build path is not covered by the existing validation
What's wrong
This PR changes the major Vite and React plugin versions used to build the published Node UI bundle, but the repository’s CI path shown in the workflow comments deliberately skips that bundle and the browser e2e lane uses the dev server. That leaves the riskiest changed behavior for this dependency bump unverified.
Example
A regression that only appears during vite build, such as an asset transform, chunking, or production-only plugin behavior change from Vite 8 / plugin-react 6, can still pass the current CI because pnpm run build:packages skips dist-ui and the e2e job runs the dev server.
Suggested direction
Add or document a targeted production-bundle validation for Node UI as part of this dependency upgrade, rather than relying only on package builds and dev-server e2e coverage.
For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the existing fast shared build behavior if needed, but add validation for the changed production Vite path, for example a targeted CI step or required local evidence running pnpm --filter @origintrail-official/dkg-node-ui run build:ui / pnpm build:runtime. The proof should fail if Vite 8 cannot produce the Node UI production bundle.
There was a problem hiding this comment.
💡 Suggestion: Centralize the frontend toolchain version policy
Why it matters
The upgrade is spread across leaf manifests with inconsistent range precision. That is manageable today, but it preserves unnecessary dependency-management friction for every future toolchain upgrade.
Suggestion
Consider using a pnpm catalog or another repo-level convention for shared build tools like vite, @vitejs/plugin-react, vitest, and @types/node, then have package manifests reference that policy consistently.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
11 times, most recently
from
cb43569 to
fb5a471
Compare
|
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
fb5a471 to
f012b44
Compare
|
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
f012b44 to
2a9ce9a
Compare
…with 7 updates Bumps the dev-tooling group with 7 updates in the / directory: | Package | From | To | | --- | --- | --- | | [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) | `22.19.11` | `26.1.1` | | [@vitest/coverage-v8](https://github.com/vitest-dev/vitest/tree/HEAD/packages/coverage-v8) | `4.0.18` | `4.1.10` | | [tsx](https://github.com/privatenumber/tsx) | `4.21.0` | `4.23.1` | | [vitest](https://github.com/vitest-dev/vitest/tree/HEAD/packages/vitest) | `4.0.18` | `4.1.10` | | [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) | `6.4.2` | `8.1.4` | | [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/tree/HEAD/packages/plugin-react) | `4.7.0` | `6.0.3` | | [@playwright/test](https://github.com/microsoft/playwright) | `1.59.1` | `1.61.1` | Updates `@types/node` from 22.19.11 to 26.1.1 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node) Updates `@vitest/coverage-v8` from 4.0.18 to 4.1.10 - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v4.1.10/packages/coverage-v8) Updates `tsx` from 4.21.0 to 4.23.1 - [Release notes](https://github.com/privatenumber/tsx/releases) - [Changelog](https://github.com/privatenumber/tsx/blob/master/release.config.cjs) - [Commits](privatenumber/tsx@v4.21.0...v4.23.1) Updates `vitest` from 4.0.18 to 4.1.10 - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v4.1.10/packages/vitest) Updates `vite` from 6.4.2 to 8.1.4 - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v8.1.4/packages/vite) Updates `@vitejs/plugin-react` from 4.7.0 to 6.0.3 - [Release notes](https://github.com/vitejs/vite-plugin-react/releases) - [Changelog](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite-plugin-react/commits/plugin-react@6.0.3/packages/plugin-react) Updates `@playwright/test` from 1.59.1 to 1.61.1 - [Release notes](https://github.com/microsoft/playwright/releases) - [Commits](microsoft/playwright@v1.59.1...v1.61.1) --- updated-dependencies: - dependency-name: "@playwright/test" dependency-version: 1.61.1 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-tooling - dependency-name: "@types/node" dependency-version: 26.0.1 dependency-type: direct:development update-type: version-update:semver-major dependency-group: dev-tooling - dependency-name: "@vitejs/plugin-react" dependency-version: 6.0.3 dependency-type: direct:development update-type: version-update:semver-major dependency-group: dev-tooling - dependency-name: "@vitest/coverage-v8" dependency-version: 4.1.9 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-tooling - dependency-name: tsx dependency-version: 4.22.4 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-tooling - dependency-name: vite dependency-version: 8.1.0 dependency-type: direct:development update-type: version-update:semver-major dependency-group: dev-tooling - dependency-name: vitest dependency-version: 4.1.9 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-tooling ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
2a9ce9a to
bb599c7
Compare
1 participant
Bumps the dev-tooling group with 7 updates in the / directory:
22.19.1126.1.14.0.184.1.104.21.04.23.14.0.184.1.106.4.28.1.44.7.06.0.31.59.11.61.1Updates
@types/nodefrom 22.19.11 to 26.1.1Commits
Updates
@vitest/coverage-v8from 4.0.18 to 4.1.10Release notes
Sourced from @vitest/coverage-v8's releases.
... (truncated)
Commits
db616d2chore: release v4.1.10 (#10718)a7a61e7chore: release v4.1.9 (#10598)e61f2ddchore: release v4.1.8e4067b3fix(browser): disable clientcdpAPI whenallowWrite/allowExec: false[ba...a09d472chore: release v4.1.7a8fd24cchore: release v4.1.6e399846chore: release v4.1.5ac04bacchore: release v4.1.42dc0d62chore: release v4.1.3fc6f482chore: release v4.1.2Updates
tsxfrom 4.21.0 to 4.23.1Release notes
Sourced from tsx's releases.
... (truncated)
Commits
79fdddefix(watch): treat script and dependency paths literallye818ad6perf: index transform cache lazilycdcc623perf: map Node TypeScript formats directlyd067938perf: load esbuild lazily in CLI95d0672fix(watch): avoid clearing piped output6fd4607docs: add per-page metadataf4176d8docs: generate sitemap8d4ffc2fix: support tsImport after global preloadf0e89b2docs: document Node's public type-stripping API vs internal loader pathf8992f1perf: use sync module hooks on Node v22.22.3+Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for tsx since your current version.
Updates
vitestfrom 4.0.18 to 4.1.10Release notes
Sourced from vitest's releases.
... (truncated)
Commits
db616d2chore: release v4.1.10 (#10718)bae52b5fix(vm): fix external module resolve error with deps optimizer query for enco...a7a61e7chore: release v4.1.9 (#10598)934b0f5fix(pool): prevent test run hang on worker crash (#10543) [backport to v4] (#...7fb2965fix(browser): wait for orchestrator readiness before resolving browser sessio...a518019fix: fiximportOriginalwith optimizer and query import [backport to v4] (#...e61f2ddchore: release v4.1.8e4067b3fix(browser): disable clientcdpAPI whenallowWrite/allowExec: false[ba...a09d472chore: release v4.1.7a8fd24cchore: release v4.1.6Updates
vitefrom 6.4.2 to 8.1.4Release notes
Sourced from vite's releases.
... (truncated)
Changelog
Sourced from vite's changelog.
... (truncated)
Commits
a477454release: v8.1.4ab5dafafeat(legacy): prefer oxc as minifier (fix #21973) (#22468)173a1b6fix(ssr): align named export function call stacktrace column with Node (#22829)575c32cfix(build): add workaround for building on stackblitz (#22840)72a5e21fix(optimizer): avoid optimizer run for transform request before init (#22852)a9539d6chore(deps): update dependency postcss-modules to v9 (#22867)70435b2docs: fix incorrect@defaultforserver.cors(#22859)2c4a217build: remove the custom onLog function (#22878)c581b55build: replace deprecatedonwarnwithonLog(#22741)ea22fb3refactor: eliminate ineffectiveDynamicImport warn (#22876)Updates
@vitejs/plugin-reactfrom 4.7.0 to 6.0.3Release notes
Sourced from @vitejs/plugin-react's releases.
... (truncated)
Changelog
Sourced from @vitejs/plugin-react's changelog.
... (truncated)
Commits
640fd35release: plugin-react@6.0.3889efb0fix(deps): update all non-major dependencies (#1249)6c57dd4fix(plugin-react): use '/' base in bundledDev preamble to fix non-root base p...3cc33a7fix(deps): update react-related dependencies (#1245)c0f7c7fdocs: mention the Biome rule in the "Consistent components exports" section (...cd80f0ffix(deps): update all non-major dependencies (#1241)e38accafix(deps): update all non-major dependencies (#1227)9a9bb26perf(react): improve react compiler preset so that slightly more modules are ...6535b55release: plugin-react@6.0.2bf0e43bfeat(react): whitelist debugging-options (#1189)Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for
@vitejs/plugin-reactsince your current version.Updates
@playwright/testfrom 1.59.1 to 1.61.1Release notes
Sourced from @playwright/test's releases.
... (truncated)
Commits
39e3553cherry-pick(#41399): fix(test): load require-reached files as commonjs in syn...4328122chore: mark v1.61.1 (#41404)2c29a94fix(tracing): stop recording websocket frames outside of chunks (#41398)4324b19cherry-pick(#41367): fix(test): keep builtin expect matchers on base extend041e7e3cherry-pick(#41364): fix(har):WebSocketmessage timestamps should be in mi...b8a0fc3cherry-pick(#41309, #43149): Revert "fix(firefox): treat `navigationCommitted...b5a3175cherry-pick(#41319): fix(loader): support other node versionsd4724a9cherry-pick(#41290): feat(docker): add Ubuntu 26.04 (Resolute Raccoon) image1cc5a90cherry-pick(#41295): chore: PLAYWRIGHT_TRACING_NO_WEBSOCKET_FRAMES and PLAYWR...a6772bdcherry-pick(#41280): Revert "fix(trace-viewer): add keyboard navigation to `N...